安安～我是ChiYu～
取消「進行中」Filter Chip 後，成員資料從 8 筆回到 24 筆。24 筆本身不會自動把 Table 升級；真正把需求往 Data Table 推的，是管理員接著要搜尋、篩選、多筆選取，再批次停用帳號。
於是，一句很有氣勢的 Prompt 差點就能直接收工：
幫我做一個功能完整的企業級 Data Table。
下面是依照第一版需求重建的錯誤現場。畫面使用虛構成員資料，不含真實個資：
圖 1：實際任務只有選取兩位離職成員並停用帳號，第一版卻把十一個工具列控制項、可排序表頭、列選單與分頁一起開滿。
「企業級」三個字交給 AI，效果通常很穩定。搜尋、排序、篩選、分頁、核取方塊、固定表頭、欄位拖曳、每列三點選單會陸續報到，儲存格最好還能直接編輯。功能像吃到飽一樣擺滿，至於使用者有沒有要吃，等等再說。
問題是，表格每多一項能力，就多一份狀態、鍵盤、跨頁與手機版規則。使用者若只想讀一份三欄費用報表，端上 Grid 等級的互動，不會讓資料更專業，只會讓閱讀先背一套操作手冊。
今天反過來做：從只能讀與比較的 Table 開始。每增加一項能力，都要回答兩題：
答不出來，功能就先留在門外。
完整 Demo 與選型階梯整理在 Vibe UI Atlas 的表格比較頁。
LumenDesk 的管理員需要搜尋姓名、依狀態篩選、調整排序，還要勾選多位成員後停用帳號。這些任務已經超過靜態 Table，但仍然沒有欄位拖曳、任意儲存格編輯或父子階層的需求。
我先替功能記一筆帳：
| 新增能力 | 它解決的任務 | 同時新增的規格 |
|---|---|---|
| 排序 | 依姓名、日期或狀態重新排列 | 目前欄位、方向、空值與同值規則 |
| 篩選 | 只看符合條件的資料 | 已套用條件、AND／OR、零結果與清除方式 |
| 多列選取 | 對多位成員執行同一操作 | 跨頁保留、全選範圍、取消與部分失敗 |
| 分頁 | 管理大量結果的閱讀範圍 | 總筆數、每頁筆數、網址、切頁焦點與條件保留 |
| 列操作 | 處理單一成員 | 操作對象、權限、危險確認與完成回饋 |
| 儲存檢視 | 讓使用者回到相同欄位與條件 | 偏好保存、版本變更與還原預設 |
這張表是今天的煞車。AI 加一個按鈕很快，但按鈕背後的查詢狀態、選取範圍與錯誤恢復不會因此自動完成。
先把常見名稱放回能力階梯：
只需要讀與比較列欄資料
→ Table
需要搜尋、排序、篩選、選取、分頁或列操作
→ Data Table，只加入有明確任務的功能
需要方向鍵在儲存格間移動、選取或編輯
→ Grid
同時有父子階層與多欄互動資料
→ Treegrid
Bulk Action Toolbar、Pagination 與 Overflow Menu 是 Data Table 可能需要的配套，不是更高級的表格類型。每加一個，就多一條顯示條件、狀態更新或鍵盤路徑要驗收。
Table 適合有明確列與欄關係的資料，例如部門、月份與費用。使用者能由上往下比較同一欄，也能由左往右理解一筆資料。
圖 2：三筆費用以固定列欄呈現，表格本體維持閱讀用途，排序由明確按鈕處理。
這個畫面裡，欄標題、列標題、Caption 與金額格式比陰影和斑馬紋更重要。儲存格不用為了看起來厲害就全部取得焦點，讀者也不需要先學方向鍵才能找到一個數字。
W3C 的 Table Pattern明確區分 Table 與 Grid：Table 是靜態表格式結構，儲存格本身不需要可聚焦或可選取。能用原生 HTML Table 表達關係時，我會先保留 <table>、<th>、scope 與 <caption> 的語意，不急著用 ARIA 重新組裝一次。
表格很寬時，也不要立刻把所有欄位藏掉。先確認主要比較欄位，再決定局部水平捲動、摘要版面或詳細頁。手機版的目標不是「看不到捲軸」，而是主要任務真的能完成。
Data Table 不是原生 HTML 元件名稱。它是產品與 Design System 常用的組合，在 Table 上加入搜尋、排序、篩選、選取、分頁與列操作。
圖 3：成員 Data Table 支援搜尋、篩選、選取與批次操作；留下的能力都有對應管理任務。
LumenDesk 會保留姓名搜尋、狀態篩選、排序、多列選取和分頁，因為管理員真的會用到。欄位拖曳沒有對應任務，就不會因為「企業級」先塞進來；使用者從不調欄寬時，那套拖曳、保存與還原規則只是在替未發生的問題加班。
這些功能也不是各自活在一座小島。它們共用至少四組狀態：
| 狀態 | 內容 | 常見錯誤 |
|---|---|---|
| 查詢狀態 | 關鍵字、篩選、排序、頁碼、每頁筆數 | 改篩選後仍停在不存在的第 8 頁 |
| 結果狀態 | Loading、資料、Empty、Error、總筆數 | 頁碼更新了，資料仍是上一頁 |
| 選取狀態 | 已選 ID、全選範圍、不可操作項目 | 畫面說選 2 筆，後端收到 24 筆 |
| 寫入狀態 | 確認、處理中、部分成功、失敗與重試 | 批次停用失敗後，所有列仍顯示成功 |
只要搜尋、篩選、分頁與選取各自保存一份世界觀，使用者很快就會遇到「畫面說一套、實際操作另一套」的版本。
24 筆資料可以在前端完成搜尋與排序，但正式產品可能有 24,000 筆。這時要先決定查詢在哪裡執行：
Server-side Data Table 還要處理請求競態。使用者快速輸入 O、Or、Orbit 時，較舊的 O 查詢可能最後才回來；若前端照單全收，畫面會被舊結果蓋回去。可以取消舊請求、使用 Request ID，或只接受目前查詢版本的回應。
搜尋延遲、快取與 URL Query 也要一起決定。這些不會畫在漂亮截圖裡，卻直接影響資料是否可信。
Bulk Action Toolbar 是 Data Table 的批次操作配套。尚未選取資料時，它沒有操作對象，不必全年無休佔在表格上方；選取一筆以上後，再顯示數量、可用操作與取消選取。
圖 4：選取林子安與陳可欣後，工具列顯示「2 位成員已選取」與批次停用操作。
最麻煩的通常是「全選」。到底只選本頁 20 筆，還是符合篩選的 2,430 筆？兩者差了 2,410 個帳號，後面的確認 Dialog 再漂亮也補不回這行沒寫清楚的規則。
LumenDesk 這次明確採用「只選目前頁」；若產品提供「選取全部篩選結果」，畫面要先顯示本頁數量，再提供第二步擴大範圍，例如：
已選取本頁 20 位成員。選取符合條件的全部 2,430 位？
批次操作完成後，也不能只回一個總成功 Toast。若 20 筆裡有 2 筆因權限或資料版本失敗，畫面要列出成功、失敗與可重試對象，並保留失敗列的選取。全部塗成成功，只是把例外藏進統計數字裡。
Pagination 把長資料集拆成多頁，適合需要知道目前位置、回到某一頁，或保留穩定結果範圍的工作。
圖 5：分頁控制顯示目前位置、可前往頁面與資料範圍，讓切頁結果可以被確認。
需求至少要定義：
LumenDesk 切頁後把焦點移到資料表標題，因為管理員要重新確認結果範圍；其他流程也可能保留焦點在分頁按鈕，再用 Status Message 宣告新資料。重點不是背一個固定落點，而是切頁後不能讓使用者失去位置。
資料若持續更新、使用者只需要一路瀏覽，Load More 或 Infinite Scroll 可能更自然；它們同樣要處理瀏覽器返回位置、頁尾可達性、載入失敗與可分享網址。換一種捲動方式，規格不會跟著蒸發。
每列右側的三點選單適合收納低頻或次要操作，例如複製連結、封存與停用。高頻主要操作不該只因為版面擠，就全部被塞進三個點裡。
圖 6：Overflow Menu 收納單列次要操作，危險動作保留名稱、對象與後續確認。
三點按鈕要有完整名稱，例如「林子安的更多操作」。打開後，選單項目不能只寫「刪除」，而應說出「停用林子安帳號」或在後續 Confirmation Dialog 明確顯示對象。完成、取消或關閉後，焦點也要回到原列入口。
資料重新排序或分頁後，焦點返回不能只靠陣列位置。若原本第 3 列已移動，系統應依穩定 ID 找回對象；對象已被刪除時，再移到下一個合理位置並說明結果。
Grid 適合需要在儲存格間移動、選取或編輯的密集資料，例如排班表、權限矩陣或試算表。它不是在 Table 外面加上 role="grid"，就能原地轉職。
圖 7：Grid 把權限矩陣的儲存格變成可操作位置，使用者透過方向鍵在內部移動。
W3C 的 Grid Pattern說明，Grid 是複合型元件，通常只保留一個 Tab 進入點，再由方向鍵於內部移動。這會改變一般網頁鍵盤閱讀方式，也代表我們必須處理焦點位置、選取、編輯模式與離開方式。
若儲存格可編輯，還要決定 Enter、F2、Escape 與 Tab 的行為；儲存失敗時，焦點不能離開後才偷偷顯示錯誤。如果每個儲存格只顯示文字，原生 Table 往往更穩定。為了少按幾次 Tab，把簡單報表升級成 Grid，省下的按鍵可能還沒有新增的 bug 多。
Treegrid 同時處理父子階層與多欄資料，適合組織預算、專案工作分解或有子資料列的報表。使用者既要知道自己在哪一層，也要比較欄位與展開收合。
圖 8：Treegrid 同時呈現父子層級與多欄資料，列可以展開，欄位仍能互相比較。
W3C 的 Treegrid Pattern定義方向鍵、Home、End 與展開收合等互動。若子節點要從後端載入，還要補上 Loading、Empty、Error、Retry，以及收合後如何取消或保留請求。
若只是想把一列明細藏起來，Expandable Row 比較容易理解；資料只有階層、沒有多欄比較時，Tree View 更直接。LumenDesk 的成員名單兩種條件都不符合，所以停在 Data Table，不往 Treegrid 硬升級。
圖 9：資料從閱讀、管理走到儲存格互動與父子階層時，表格能力和操作成本一起增加。
LumenDesk 最後停在 Data Table。留下姓名搜尋、狀態篩選、排序、多列選取、範圍清楚的 Bulk Action Toolbar、Pagination 與 Overflow Menu；欄位拖曳、任意儲存格編輯和 Treegrid 沒有加入。
360px 版面保留成員、狀態與主要操作，其他欄位移進可到達的詳細內容，不是直接從 DOM 和任務裡一起消失。資料若多到需要虛擬化，也要確認螢幕閱讀器、搜尋、列數與焦點不會只看得到目前渲染的幾列；效能優化不能把資料語意一起裁掉。
請為 LumenDesk 建立成員管理 Data Table，不要預設加入所有進階功能。
- 欄位：成員、部門、狀態；使用正確的表格標題與資料關係。
- 支援搜尋姓名、依狀態篩選、依成員排序與多列選取。請明確定義搜尋與排序在前端或後端執行，並避免舊請求覆蓋新結果。
- 尚未選取時隱藏 Bulk Action Toolbar；選取後顯示數量、取消選取與停用帳號。
- 全選只選目前篩選結果中的本頁資料。若日後支援全部結果，必須另外顯示總範圍並再次確認。
- Pagination 顯示目前 21–40／共 236 筆；切頁後保留篩選與排序，更新 URL Query，並讓使用者知道新的結果範圍。
- 每列 Overflow Menu 包含查看詳細、複製連結、停用帳號；觸發按鈕與危險操作都要包含成員名稱。
- 批次操作提供確認、處理中、部分成功、失敗與重試；不可把部分失敗統一顯示成成功。
- 提供 Loading、Empty、Error、零搜尋結果與權限不足。
- 360px 保留成員、狀態與主要操作；其他欄位進入詳細內容，不得讓整頁水平溢出。
這份 Prompt 沒有禁止 AI 做出好看的表格。它只是先把全選範圍、查詢競態、切頁狀態、危險操作對象與部分失敗釘住，避免外觀看起來完成，資料規則還在自由發揮。
交付前，我會依序檢查：
目前 Data Table 的選取、批次工具列、360px 瀏覽器版面與一般鍵盤路徑已驗證。Grid、Treegrid 的複合鍵盤模型、虛擬化與手機實機仍待複驗，文章就停在這條證據線上，不讓「企業級」三個字替它們補考。
開頭那句「功能完整的企業級 Data Table」最後被拆成一組有任務的能力。LumenDesk 停在 Data Table，沒有為了氣勢升級成 Grid 或 Treegrid。
表格把我帶進一筆活動專案後，詳細頁要放六張場地照片和一段教學影片。我又順手交給 AI：
做一個有圖片輪播和影片的漂亮產品頁。
結果照片每五秒自動切換，標題壓在圖片上，旁邊還擺了一支影片。
圖 10：六張場地照被塞進自動輪播，但沒有暫停控制；圖片失敗只剩「活動圖片」，關閉 Lightbox 後焦點還回到頁首。
圖片是在提供資訊、供人挑選、輪流展示，還是放大檢視？問題一換，元件也會跟著換。明天就來拆 Image、Thumbnail、Gallery、Carousel、Lightbox、Video Player 與 Aspect Ratio。
資料查閱：2026-08-07。
iThome鐵人賽
看影片追技術